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REMARKS 

Claims 1, 3-11, and 13-21 are rejected in the application. Claims 2 and 12 were 
previously canceled. Claims 1, 3-11, and 13-21 remain in the application. 

Claim Rejections under 35 U.S.C. § 103 

Claims 1,3-11 and 13-20 were rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Kimura et al., U.S. Patent No. 6,105,127 (hereinafter "Kimura") in view of Olarig et al., 
U.S. Patent No. 5,944,809 (hereinafter "Olarig"). 

As recited in independent claims 1, 10, 1 1, and 20, a counter is provided that has a value 
selected depending on the priority assigned to the thread. Allocating a resource between a 
plurality of threads is controlled based on the counter (see pages 7-8 of the filed application). In 
one embodiment, the counter value can bet set high when a high priority is given to a thread, and 
set to a low value when a low priority is given to a thread. The cited references fail to teach or 
suggest this feature of the independent claims. 

As stated in the Office Action, Kimura fails to disclose "a counter loaded with a 
predetermined value by control logic for each thread in the memory, such that the value being 
selected depending on the priority assigned, and the counter being used to allocate said resource 
between a plurality of threads." (Office Action, p. 3). 

The Office Action relies on Olarig make up for the deficiencies of Kimura. In particular, 
the office action points to LOPIC and COPIC as being "threads" and a two-bit counter used to 
allocate resources between LOPIC and COPIC. As shown in Fig. 3, multiple CPUs are shown 
(elements 15 and 106), each with a "LOPIC" (elements 305, 306, respectively; "local 
programmable interrupt controller). The Office Action first cites to Col. 3, lines 22-38. The first 
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sentence of this paragraph states that it applies to "balancing the interrupt loading among various 
processors in a scalable MP [multiprocessor] system." A counter is associated with each 
processing unit, and that counter is incremented each time an I/O interrupt is dispatched to that 
processing unit (Col. 3, lines 36-38). In the prior art example of Fig. 1, four processors are 
provided (CPU1 105 being one of them), and a two-bit counter is associated with each CPU. 
Each CPU is initialized with a value 00, 01, 10, or 1 1 so that each processor has a different two 
bit value. When an I/O interrupt is sent to one of the processors, each of the processors' two-bit 
counters are incremented by 1. (Col. 6, lines 42-57). The counters serve to provide a "round- 
robin" system for allocating the interrupt to the appropriate processor. In effect, one of the 
counters will have the lowest (or highest) value, and each time an I/O interrupt is sent to one of 
the processors, the counters are all incremented so that a new one of the processors will have the 
lowest (or highest) value. This assignment of the lowest (or highest) value is shared evenly 
among the four processors. 

Claim 1, for example, provides a method where a single processor is to execute a 
plurality of threads. A counter is provided "with a predetermined value for [the] plurality of 
threads, [the] value being selected by control logic depending on the priority assigned to each 
thread." Neither of these features are shown in Olarig. First, Olarig is quite clearly associated 
with balancing workload for interrupts among several different processors, not a single processor 
executing such code. Second, Olarig does not provide control logic that selects the value for the 
counter "depending on the priority assigned to each thread." In Olarig, the values for the 
counters are essentially random in that it doesn't matter which processor has which value, just as 
long as the four values are different (avoiding any "ties" when seeking to have one of the 
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processors execute code to handle an I/O interrupts). Thus, the counter in Olarig is merely a 
round robin identifier for each of the four processors to execute its own LOPIC code. 

Though counters are well known in the art, there is no description or suggestion in the Kimura 
and/or Olarig references to provide a counter for allocating resources in a multi-threaded environment as described 
in claim 1 . The rerraining independent claims, claims 10, 1 1, and 20, include similar limitations as found in claim 
1 . Since these features are neither taught nor suggested by the Kimura or Olariq references (taken individually or in 
combination), reconsideration and withdrawal of the rejection of claims 1,3-11, and 13-21 under 
35 U.S.C. § 103(a) is respectfully requested. 
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CONCLUSION 



For all the above reasons, the Applicants respectfully submit that this application is in 
condition for allowance. A Notice of Allowance is earnestly solicited. 

The Examiner is invited to contact the undersigned at (202) 220-4255 to discuss any 
matter concerning this application. The Office is hereby authorized to charge any additional fees 
or credit any overpayments under 37 C.F.R. §1.16 or §1.17 to Deposit Account No. 11-0600. 



KENYON & KENYON 
1500 K Street, NW, Suite 700 
Washington, D.C. 20005-1257 
(202) 220-4200 telephone 
(202) 220-4201 facsimile 
DCl-618677vl 



Respectfully submitted, 



KENYON & KENYON 



Dated: July 6, 2006 




Shawn W. O'Dowd 
Reg. No. 34,687 
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